To load user data, provide an index which points to a particular memory location. A valid index is expressed as 3 hexadecimal digits, and must be within the range X'000 to X'FFF.
An index points to a key block. This varies in length depending on the key length specified in the CS (Configure Security) console command. For example, if loading two encrypted working keys and specifying X'000 as the base index, the first encrypted key is stored in bytes 0-7; the second encrypted key is stored in bytes 8-15.
|
|
Single Length |
Double Length |
Triple Length |
||||||
|
Location 000 |
Byte 0 |
|
Byte 7 |
Byte 8 |
|
Byte 15 |
Byte 16 |
|
Byte 23 |
|
Location 001 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Location FFE |
|
|
|
|
|
|
|
|
|
|
Location FFF |
|
|
|
|
|
|
|
|
Byte 98303 |
Data can be stored in continuous bytes, or in discrete areas of memory. The only requirement for index assignment applies to storage of the Diebold table. This table must be stored as 256 contiguous bytes. Thus, X'3E0 is the highest possible base index that can be specified when the Diebold table is loaded or accessed.
It is the programmer's responsibility to assign and keep track of the indices. When an index is provided to load new data, the HSM does not check the memory location to determine if it already contains data. If the wrong index is provided, the data overwrites the previous contents. For example, if X'000 is specified as the base index when loading the Diebold table, and the same index is then used to load an encrypted key, the table is invalidated.